…elid,xFrednet

Update pulldown-cmark version to 0.9

Fixes rust-lang#92206.

r? `@camelid`

Clippy helpfully warns about code like this, telling you that you
probably meant "write_all":

    fn say_hi<W:Write>(w: &mut W) {
       w.write(b"hello").unwrap();
    }

This patch attempts to extend the lint so it also covers this
case:

    async fn say_hi<W:AsyncWrite>(w: &mut W) {
       w.write(b"hello").await.unwrap();
    }

(I've run into this second case several times in my own programming,
and so have my coworkers, so unless we're especially accident-prone
in this area, it's probably worth addressing?)

This patch covers the Async{Read,Write}Ext traits in futures-rs,
and in tokio, since both are quite widely used.

changelog: [`unused_io_amount`] now supports AsyncReadExt and AsyncWriteExt.

This improves the quality of the genrated output and makes it
more in line with other lint messages.

changelog: [`unused_io_amount`]: Improve help text

…Frednet

Extend unused_io_amount to cover async io.

Clippy helpfully warns about code like this, telling you that you
probably meant "write_all":

    fn say_hi<W:Write>(w: &mut W) {
       w.write(b"hello").unwrap();
    }

This patch attempts to extend the lint so it also covers this
case:

    async fn say_hi<W:AsyncWrite>(w: &mut W) {
       w.write(b"hello").await.unwrap();
    }

(I've run into this second case several times in my own programming,
and so have my coworkers, so unless we're especially accident-prone
in this area, it's probably worth addressing?)

Since this is my first attempt at a clippy patch, I've probably
made all kinds of mistakes: please help me fix them?  I'd like
to learn more here.

Open questions I have:

  * Should this be a separate lint from unused_io_amount?  Maybe
    unused_async_io_amount?  If so, how should I structure their
    shared code?
  * Should this cover tokio's AsyncWrite too?
  * Is it okay to write lints for stuff that isn't part of
    the standard library?  I see that "regex" also has lints,
    and I figure that "futures" is probably okay too, since it's
    an official rust-lang repository.
  * What other tests are needed?
  * How should I improve the code?

Thanks for your time!

---

changelog: [`unused_io_amount`] now supports async read and write traits

…earth

fix [`redundant_closure`] fp with `Rc<F>`/`Arc<F>`

fixes rust-lang#8073

changelog: don't trigger [`redundant_closure`] on `Arc<F>` or `Rc<F>`

The `wrong_self_convention` lint uses a `SelfKind` type to decide
whether a method has the right kind of "self" for its name, or whether
the kind of "self" it has makes its name confusable for a method in
a common trait.  One possibility is `SelfKind::No`, which is supposed
to mean "No `self`".

Previously, SelfKind::No matched everything _except_ Self, including
references to Self.  This patch changes it to match Self, &Self, &mut
Self, Box<Self>, and so on.

For example, this kind of method was allowed before:

```
impl S {
    // Should trigger the lint, because
    // "methods called `is_*` usually take `self` by reference or no `self`"
    fn is_foo(&mut self) -> bool { todo!() }
}
```

But since SelfKind::No matched "&mut self", no lint was triggered
(see rust-lang#8142).

With this patch, the code above now gives a lint as expected.

Fixes rust-lang#8142

changelog: [`wrong_self_convention`] rejects `self` references in more cases

Remove existing problematic cases.

Inspired by a discussion in rust-lang/rust-clippy#8197

---

r? `@llogiq`

changelog: none

The lint is this on nightly, therefore no changelog entry for you xD

…uct, r=llogiq

return_self_not_must_use document `#[must_use]` on the type

Inspired by a discussion in rust-lang/rust-clippy#8197

---

r? `@llogiq`

changelog: none

The lint is this on nightly, therefore no changelog entry for you xD

wrong_self_convention: Match `SelfKind::No` more restrictively

The `wrong_self_convention` lint uses a `SelfKind` type to decide
whether a method has the right kind of "self" for its name, or whether
the kind of "self" it has makes its name confusable for a method in
a common trait.  One possibility is `SelfKind::No`, which is supposed
to mean "No `self`".

Previously, SelfKind::No matched everything _except_ Self, including
references to Self.  This patch changes it to match Self, &Self, &mut
Self, Box<Self>, and so on.

For example, this kind of method was allowed before:

```
impl S {
    // Should trigger the lint, because
    // "methods called `is_*` usually take `self` by reference or no `self`"
    fn is_foo(&mut self) -> bool { todo!() }
}
```

But since SelfKind::No matched "&mut self", no lint was triggered
(see rust-lang#8142).

With this patch, the code above now gives a lint as expected.

fixes rust-lang#8142

changelog: [`wrong_self_convention`] rejects `self` references in more cases

…nst one

…xFrednet

[`erasing_op`] lint ignored when operation `Output` type is different from the type of constant `0`

fixes rust-lang#7210

changelog: [`erasing_op`] lint ignored when operation `Output` type is different from the type of constant `0`

Remove `NullOp::Box`

Follow up of rust-lang#89030 and MCP rust-lang/compiler-team#460.

~1 month later nothing seems to be broken, apart from a small regression that rust-lang#89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely.

r? `@jonas-schievink`
`@rustbot` label T-compiler

…rednet

Fix `clippy::use-self`` warning in ` src/main.rs`

`ClippyCmd` warnings gets generated due to addition of `clippy::use-self`. This PR fixes that.

```
warning: unnecessary structure name repetition
  --> src/main.rs:99:9
   |
99 |         ClippyCmd {
   |         ^^^^^^^^^ help: use the applicable keyword: `Self`
   |
   = note: `-W clippy::use-self` implied by `-W clippy::nursery`
   = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#use_self
```

---

changelog: none

Consider auto-deref when linting `manual_swap`

fixes rust-lang#8154

changelog: Don't lint `manual_swap` when a field access involves auto-deref

…st equal hashes

Allow `_` as the length of array types and repeat expressions

r? `@BoxyUwU` cc `@varkor`

changelog: none

Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs.

Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy`

Fixes rust-lang#7843 by not parsing every node of macro implementations, at least the major offenders.

I probably want to get rid of `is_expn_of` at some point.

New macro utils

changelog: none

Sorry, this is a big one. A lot of interrelated changes and I wanted to put the new utils to use to make sure they are somewhat battle-tested. We may want to divide some of the lint-specific refactoring commits into batches for smaller reviewing tasks. I could also split into more PRs.

Introduces a bunch of new utils at `clippy_utils::macros::...`. Please read through the docs and give any feedback! I'm happy to introduce `MacroCall` and various functions to retrieve an instance. It feels like the missing puzzle piece. I'm also introducing `ExpnId` from rustc as "useful for Clippy too". `@rust-lang/clippy`

Fixes rust-lang#7843 by not parsing every node of macro implementations, at least the major offenders.

I probably want to get rid of `is_expn_of` at some point.

Remove in_macro from clippy_utils

changelog: none

Previously done in rust-lang#7897 but reverted in rust-lang#8170. I'd like to keep `in_macro` out of utils because if a span is from expansion in any way (desugaring or macro), we should not proceed without understanding the nature of the expansion IMO.

r? `@llogiq`

`manual_memcpy` fix

fixes rust-lang#8160

Ideally this would work with `VecDeque`, but the current interface is unsuitable for it. At a minimum something like `range_as_slices` would be needed.

changelog: Don't lint `manual_memcpy` on `VecDeque`
changelog: Suggest `copy_from_slice` for `manual_memcpy` when applicable

Rustup

r? `@ghost`

changelog: none